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INTRODUCTION 

Fieldbuses are communication networks specifically con- 
ceived for applications in factory automation systems. They 
have started to be deployed, approximately, at the beginning 
of the 1990s and since then their growth has been impres- 
sive: indeed, it is estimated that several hundreds of million 
fieldbus nodes are currently installed. 

Factory automation systems are typically organized 
according to a hierarchical structure, as shown in Figure 42.1, 
where the use of communication networks is highlighted. 
Particularly, as can be seen, fieldbuses are employed at the 
device level or field level as well as at the cell level. 

At the device level, fieldbuses provide communication 
between device controllers and sensors/actuators. Two types 
of operation are mainly performed at this level: cyclic data 
exchange and acyclic transmission. 

Cyclic data exchange is represented by the polling opera- 
tion carried out by the device controllers on sensors/actua- 
tors. Usually, the amount of data exchanged is small (some 
tens of bytes), but the cycle times required may be of a few 
milliseconds, or even less. 

The acyclic transmission is represented by the asynchro- 
nous exchange of data necessary to notify the occurrence of 
an unpredictable event such as an alarm from a sensor node 
to a device controller. Also in this case, the amount of data 
exchanged is small, but the maximum allowed notification 
time (alarm latency) may be on the order of some milliseconds. 

At the cell level, the operations of device controllers are 
coordinated and monitored. This implies the transfer of con- 
siderable quantities of data, for configuration, calibration, 
trending, etc. In this case, however, the times allowed for the 
data transfer can be on the order of hundreds of millisec- 
onds or more. These operations are provided by messaging 
services, which are typical of the protocols employed at this 
level. Fieldbuses have been traditionally used at the cell level 
even if, however, in the last years local area networks have 
become profitably adopted as well. 

This section describes the features of some very popular 
fieldbuses that are employed in several applications related to 
different types of industrial plants. 

For each fieldbus considered, the communication profile 
is reported and compared with that typical for fieldbuses, 
shown in Figure 42.2. 


Considerable attention is dedicated to the data link layer 
characteristics (in particular to the protocol data units [PDUs] 
that, at this layer, are also called frames) as they influence 
the overall behavior of a communication network. The data 
link layer, actually, is responsible for the access to the physi- 
cal medium and for the correct transfer of the data. Some 
popular niche fieldbuses, namely, DeviceNet, ControlNet, 
Lonworks, WorldFIP, AS-i, and Sercos, are explained in 
detail in following sections. 

DeviceNet 

DeviceNet is a fieldbus included in both the EN50325 [1] and 
IEC6202 [2] standards and supported by the Open DeviceNet 
Vendor Association (ODVA, www.odva.org). It has been 
realized mainly for use at the device level of industrial auto- 
mation systems where it implements the communication 
between the device controller and sensors/actuators. 

DeviceNet has a widespread use and it is adopted in vari- 
ous applications. Some of the most important applications 
are in electrical energy distribution plants, the food and bev- 
erage industry, chemical plants, oil and gas production, and 
distribution systems. 

The communication profile of DeviceNet is shown in 
Figure 42.3. As can be seen, at the lower layer, the well- 
known Controller Area Network (CAN) [3] protocol is 
used to access the physical medium. At the application 
layer, DeviceNet makes use of the well-assessed Common 
Industrial Protocol (CIP) [4], formerly known as Control and 
Information Protocol, which is adopted by other popular 
networks such as Ethernet/IP, ControlNet, and CompoNet. 
Clearly, the choice of a common application layer protocol 
enables a high degree of interoperability among the afore- 
mentioned networks. 

Physical Layer 

DeviceNet uses the CAN physical layer signaling (PLS). 
One of the major advantages deriving from this choice is the 
availability of chips implementing the CAN protocol from 
many suppliers. 

The typical network configuration is a bus constituted 
by a trunk line from which several drop lines are derived to 
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FIG. 42.1 

Typical structure of factory automation systems. 
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FIG. 42.2 

Typical communication profile of a fieldbus. 


connect stations. There is also the possibility of arranging the 
drop lines with daisy chains and branches especially for use 
inside control panels. 

A maximum of 64 nodes can be connected to the network. 

DeviceNet foresees the possibility of powering the sen- 
sors directly from the network, therefore, the trunk cable 
comprises two twisted pairs: one is used for the data transfer 
and the other for the power distribution. 

Three different data transfer speeds are selectable: 125, 
250, and 500 kbit/s. The correspondent maximum distances 
coverable by the trunk line are, respectively, 500, 250, and 
100m. 

Data Link Layer 

The DeviceNet data link layer uses the CAN Medium 
Access Control (MAC) and Logical Link Control (LLC) 
sublayers. 

CAN is based on a Producer/Consumer model whose 
technique to access the physical medium is known as Carrier 
Sense Multiple Access (CSMA) with Collision Detection. It 
is similar to that used by Ethernet networks [5], but in this 
case, a deterministic procedure, based on the priority of the 
transmitted frames, is used to resolve the contentions on the 
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FIG. 42.3 

DeviceNet communication profile. 
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FIG. 42.4 

CAN data frame and example of arbitration phase. 


bus deriving from collisions. This procedure, which is non- 
disruptive, allows avoiding the wasting of bandwidth. 

In detail, as shown in Figure 42.4, each data frame trans- 
mitted on the network has an arbitration field that is con- 
stituted by an 11 bit identifier field plus another bit called 
Remote Transmission Request (RTR). The arbitration field 
determines the priority of the frame. 

A 0 logical value is called dominant, while a 1 logical 
value is called recessive. 


As CAN stations are connected to the network via an open 
collector stage, when two or more of them transmit simulta- 
neously, dominant bits overrule recessive bits. Consequently, 
if a station while transmitting a recessive bit detects on the 
network a dominant bit, it realizes that at least another sta- 
tion is sending a frame of higher priority and hence stops its 
transmission. 

The stations that lost the arbitration will attempt to resend 
the frames at the end of the current transmission. 
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The structure of a CAN data frame, shown in Figure 
42.4, illustrates that a maximum of 64 bits of user data can 
be transmitted with each identifier. This figure also shows an 
example of the CAN arbitration phase. 

A station wishing to send on the network the data associ- 
ated with an identifier simply transmits the relevant frame. 

Instead, if a station needs to know the data associated 
with an identifier of which it is not the producer, then it has 
to send a frame, known as a remote frame, specifying the 
desired identifier, with the RTR bit set to the recessive value 
and with the data field empty. 

It has, however, to be pointed out that DeviceNet does not 
use the CAN remote frames. 

Application Layer 

According to the CIP protocol, the DeviceNet application 
layer is based on the definition of objects that represent an 
abstract description of the components of a station. 

In practice, a station connected to DeviceNet is consid- 
ered as a collection of objects that, consequently, may be 
transmitted on the network. 

In the context of the CIP protocol, a class is defined as 
a group of objects representing the same type of component. 
An instance is the real occurrence of an object and the attri- 
butes describe its characteristics. The behavior specifies how 
an object performs, while a service identifies a function sup- 
ported by an object. 

Each DeviceNet station has an assigned address known 
as the MAC Identifier (MAC ID). 

The DeviceNet application layer protocol specifies that 
any data exchange between stations can only take place over 
logical connections, which are communication paths estab- 
lished between applications resident on different stations. 

Two types of connections are defined: I/O connections 
and Explicit Messaging Connections. I/O connections are 
intended for time-critical data transfer: they provide for the 
data exchange between a producing application and one or 
more consuming applications. 

Explicit Messaging Connections are used for general 
purpose point-to-point communication between devices. 
They are particularly suitable for low-priority, asynchronous 
data exchange. 

DeviceNet uses CAN frames to implement the functions 
specified by its application layer protocol. These frames have 
been divided into four groups, from Group 1 to Group 4, with 
decreasing priority. 

The 11 bit CAN identifier field contains the information 
necessary to classify the frames: in particular, it includes a 
Message ID and (excepting for Group 4) the MAC ID, which, 
depending on the message group, can be either the source or 
destination MAC ID. 

The 64 bit CAN data field is used to transmit the informa- 
tion related to the connection between devices. For example, 
it can be used either to specify a service request or to carry 
process data. If the available 64 bits are not sufficient to 


complete a transmission, then the protocol makes use of a 
fragmentation technique to split data for transmission and its 
subsequent reassembly. 

When establishing a connection, particular care has to be 
taken to choose the message group: if, for example, a Group 
1 message (which has high priority) is used to set an Explicit 
Messaging Connection, then it could slow down the data 
exchange related to I/O connections also occurring in Group 1. 

An important feature of the DeviceNet application layer 
protocol is represented by the Predefined Master-Slave 
Connection Set. It defines a group of customized con- 
nections that are particularly suitable for Master-Slave 
relationships. 

The Predefined Master-Slave Connection Set has been 
conceived to considerably reduce the steps necessary to set 
up a connection between applications. 

In practice, a master device to activate the Predefined 
Master-Slave Connection Set has first to send a service 
request (Allocate Master-Slave Connection Set) to the slaves 
with which it intends to exchange data, specified by a scan 
list loaded in precedence on the master. A subsequent request 
issued by the master (Set Attribute Single, relevant to the 
expected_packet_rate attribute of the connection) has the 
effect of establishing the connection. 

With the Predefined Master-Slave Connection Set, 
the data exchange may take place using one of four differ- 
ent methods. The master selects which method to use in 
the above-mentioned Allocate Master-Slave Connection 
Set service request. These methods are the bit strobe com- 
mand/response messages, intended for the exchange of small 
amounts of data; the poll command/response messages, to 
be used for the transfer of any amount of data; the change of 
state/cyclic messages, used for triggered data exchange; and 
the explicit response/request messages. 

The bit strobe command is an I/O message sent by the 
master to all the slaves defined in its scan list. This message 
carries 64 bits of output data, 1 bit for each slave. Obviously, 
if a slave is not present, or not included in the scan list, the 
relevant bit has no meaning. 

The bit strobe responses are I/O messages sent from each 
slave to the master in response to the command message. 
They can contain up to 64 bits of input data (and hence each 
of them is transmitted with just one CAN frame). 

The poll command is an I/O message, containing any 
amount of data, sent by the master to a single slave. This lat- 
ter with the poll response I/O message may also return data. 

The change of state/cyclic messages that can be transmit- 
ted are either by the master or by a slave. They are normally 
triggered by specific events such as an alarm or the expiring 
of a timer. These messages are used to implement the cyclic 
data exchange as well as the acyclic transmission functions 
typical of the fieldbuses when employed at the device level of 
factory automation systems. 

The explicit response/request is general purpose mes- 
sages used, for example, to transfer the values of some 
attributes. 
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CONTROLNET 

ControlNet is a fieldbus included in the IEC61158 standard 
[6-9], where it is referred as communication profile #2/1 
(Type 2 network), supported by the same organization of 
DeviceNet (www.odva.org). It has been designed to be used 
at both the device and cell levels of industrial automation 
systems. 

Typical applications of ControlNet can be encountered, 
for example, in complex batch control systems, the process 
industry, and the automotive industry. 

The communication profile of ControlNet is shown in 
Figure 42.5. As can be seen, differently from the typical 
fieldbus communication profile shown in Figure 42.2, in this 
case, the network, transport, and presentation layers are not 
empty. 

Nevertheless, ControlNet, which is based on a Producer/ 
Consumer model, exhibits a good efficiency and provides 
deterministic response times. 


Physical Layer 

As shown in Figure 42.5, this layer is split into two sublayers, 
the Physical Medium Attachment (PM A) and the PLS. 

The PMA is responsible for the transmission/reception 
of signals to/from the bus and comprises all the necessary 
circuitry that is not part of the ControlNet stations. 
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FIG. 42.5 

ControlNet communication profile. 


The PFS implements the bit representation and the tim- 
ing functions required for the correct transmission of the sig- 
nals on the network. Moreover, the PFS realizes the interface 
to the data link layer. 

The ControlNet standard recommends basically two 
types of physical media: coaxial cable and fiber optic. A 
third media type, named Network Access Port (NAP), allows 
for a point to point temporary connection between two 
nodes. A NAP is often used, for example, to realize the link 
between a programming unit and a station already connected 
to ControlNet. The NAP cable has eight conductors and an 
overall shield. 

The specified coaxial cable is a RG-6 quad shield, of the 
same type of that used for the cable TV industry. Several 
topologies (e.g., bus, tree, and star networks) may be realized 
with ControlNet. 

Repeaters can be used to link segments. Each station is 
connected to a segment by means of a tap to which it is linked 
via a drop cable. The maximum segment length is related 
to the number of stations connected: 1000 m with 2 stations, 
decreasing to 250 m with 48 stations. 

The fiber-optic physical medium makes use of active star 
or active hub topology and foresees two variants depending 
on the distances to be covered. The first variant specifies a 
“short-range” system for distances up to 300m, while the 
second variant refers to “medium-range” systems with dis- 
tances of up to 7000 m. 

Considerable distances (up to 30 km) can be covered by 
complex ControlNet installations using either type of physi- 
cal media. ControlNet has a fixed transmission speed of 
5 Mbit/s and may connect a maximum of 99 stations. 

Finally, redundant physical mediums are available as an 
option for ControlNet. In this case, each station is connected 
to two lines and transmits/receives contemporaneously on 
the both. 

Data Link Layer 

Figure 42.5 shows that the ControlNet data link layer is split 
into two sublayers: the MAC and the LLC. 

The MAC is based on a time-slice algorithm called 
Concurrent Time Domain Multiple Access whose operation 
is shown in Figure 42.6. 

As can be seen, a fixed period of time, the Network 
Update Time (NUT) to which all the stations are strictly syn- 
chronized, is repeated indefinitely on the network. 

The NUT, as can be noted in Figure 42.6, is divided 
in three intervals of time: scheduled, unscheduled, and 
guardband. 

The scheduled interval is typically reserved for the trans- 
mission of real-time data. For example, both the cyclic data 
exchange and the acyclic transmission, if requested, have to 
be performed in this interval. The MAC grants each station 
the possibility of transmitting one and only one frame during 
the scheduled interval. This is accomplished by means of an 
implicit token passing procedure, which works as follows. 
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ControlNet MAC cycle time and protocol data unit. 


Each station is identified by an address called MAC ID. 
At the beginning of the scheduled interval, the station with 
the lowest MAC ID is granted to transmit a MAC frame. 
Every station connected to the network maintains an implicit 
token register, which contains the MAC ID of the transmit- 
ting station. This value is incremented by one at the end of 
the frame transmission. Immediately after, each station com- 
pares its MAC ID with that contained in the implicit token 
register, and if they match, that station has the right to trans- 
mit. If a station is not present, in the fraction of the scheduled 
interval reserved to that station, there will not be activity on 
the network. In this case, after a time-out, the MAC ID is 
newly incremented by all the stations and the implicit token 
is passed on. 

The scheduled interval ends when the maximum value 
for the MAC ID is reached. 

Subsequently, the unscheduled interval is started. In this 
period, the implicit token is still circulated among stations 
according to a round robin scheme. The duration of such an 
interval, however, is variable (because it is related to the utili- 
zation of the scheduled interval), as shown in Figure 42.6, and 
a station can be granted zero, one, or more times to access the 
network. As a consequence, the unscheduled interval does 
not allow for a deterministic access to the network and hence 
has to be used for the transmission of noncritical data. 

When the guardband interval is reached, the stations 
stop transmitting and the access to the network is granted 
to the station with the lowest MAC ID, which is called the 
moderator. 

This station transmits a special message (the modera- 
tor frame) with which all the stations synchronize for the 


beginning of a new cycle and dispatch a set of parameters 
necessary for the correct network operation. 

The structure of the MAC PDU, as shown in Figure 42.6, 
comprises a header, a trailer, and a field with the data from 
the upper layers. The latter is constituted of zero or more 
structured set of data called Lpackets, which may contain a 
maximum of 510 bytes in total. 

Network and Transport Layers 

The major task of these layers is to establish and maintain 
logical connections between applications resident on differ- 
ent stations. 

The network and transport layers contain three basic 
modules: the Unconnected Message Manager (UCMM), the 
Message Router, and the Transport Connection Manager 
(TCM). 

The UCMM provides a means for the execution of 
unconnected services, that is, it allows for the data exchange 
between applications that were not previously put in com- 
munication by a connection. In this case, each data transfer is 
independent of the others and the messages have to carry the 
full details of the destination and source applications. 

The UCMM is mainly used for handling noncritical traf- 
fic and one of its most important employments is just given 
by the data exchange services necessary to setting up a 
connection. 

The Message Router realizes the correct dispatching of 
services, inside a station, to the addressed application(s). 

The TCM is actually responsible for the handling of con- 
nections. It makes the services available that are necessary to 
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create and delete connections and to exchange data over an 
established connection. 

As ControlNet is based on a Producer/Consumer model, 
the TCM has to give the possibility of setting up either point 
to point or multicast connections. The latter type, actually, 
allows for the data produced by an application (producer) 
to be shared among all the other connected applications 
(consumers). 

The TCM defines seven classes of connections (from 
class 0 to class 6) that have different features and complexity, 
and consequently can be used for different purposes. 

Class 0, for example, is the simplest, and is called Null or 
Base. It can be either multicast or point to point and is com- 
monly used in applications such as cyclic block transfers and 
acquisition of diagnostic events. 

Class 3 is more complex; it uses a sequence number to 
identify the frames in order to avoid possible duplication of 
the transmitted data and, again, such a connection can be 
either point to point or multicast. Moreover, class 3 adds a 
return point-to-point connection used to notify a source 
application that the destinations read the data previously 
transmitted. Typical example of class 3 includes the commu- 
nications between controllers and operator interface systems, 
uploads and downloads of structured set of data, and asyn- 
chronous block transfer. 

Presentation Layer 

This layer is concerned with the data management. In par- 
ticular, it defines a common means for specifying the format 
of the data handled by the application layer. 

The ControlNet presentation layer is mainly based on 
the IEC 61131-3 standard [10], which defines elementary and 
derived data types. Examples of elementary data types han- 
dled by the presentation layer are Boolean, Integer, Floating 
Point, Character String, and Bit String. 

Application Layer 

As previously mentioned, the application layer of ControlNet 
is based on the CIP. Thus, the definitions of object , class, 
instance, behavior, and service, already seen for DeviceNet, 
are directly applicable to ControlNet. 

Also in this case, a station can be seen as a collection of 
objects that have attributes, provide services, and implement 
behaviors. 

The standard includes an object library, which contains 
the definitions of several objects to be used inside stations. 
There is, however, the possibility of defining vendor specific 
objects if necessary. 

The standard also describes a set of device profiles by 
means of which products of different manufactures that 
adhere to the same profile can be interchanged with no effects 
on the network. Products belonging to the same device pro- 
file have the same behavior, produce and/or consume the 
same group of data, and contain the same set of attributes. 


In order to illustrate the concepts relevant to object mod- 
eling used by ControlNet, two standard objects are shortly 
described in the following text: the discrete output point 
object and the position sensor object. 

The discrete output point object is used to model an out- 
put bit in a hardware component. 

The class attributes of such an object can be accessed by 
means of the Get_Attributes_All and Get_Attributes_Single 
services: they supply general information about the object 
such as the current revision and the maximum instance num- 
ber of an object currently created in this class. 

The instance attributes, depending on their character- 
istics, can be either accessed or set. To access these attri- 
butes, the same services described above are used, while to 
set the attributes, the services Set_Attributes_All and Set_ 
Attributes_Single are available. The most important attribute 
that can be set is the value and allows for the discrete output 
point object to determine the value of the output bit. 

Another important attribute is the object state, which 
reports the operational state of the object: it is defined as an 
unsigned integer number, which can assume values defined 
in a specified range. 

The behavior of the discrete output point object is 
described in the standard by means of a state event matrix 
where, for each operational state, all the possible incoming 
events and the consequent state transitions or actions are 
specified. 

The position sensor object models an absolute posi- 
tion sensor hardware component, for example, an absolute 
encoder. This object, actually, is more complete than a simple 
position sensor, as it introduces a zero offset and the limit 
position check. 

The class attributes are the same as already seen for the 
discrete output point object. 

The instance attributes are related to the actual use of 
the object. The most important of them are the value (an 
unsigned double integer that reports the absolute position), 
the low and high limits for the position, the zero offset, and 
the resolution. 

The services available in this case are Get_Attributes_ 
Single and Set_Attributes_Single, 

As for the other objects, the behavior of the position sen- 
sor object is described by a state event matrix. 

L0NW0RKS 

Lonworks is a communication system that is designed to 
operate in several applications areas, which may be config- 
ured to work as a fieldbus. This type of design is the reason for 
which, as is shown in the following, Lonworks does not have 
the typical communication profile of a fieldbus. Moreover, 
both the cyclic data exchange and the acyclic transmission 
functions typically required of a fieldbus are not directly 
implemented but have to be realized using the available com- 
munication services. 
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Lon works was originally defined by the ANSI/EIA 
709 Standard [11] and recently by the ISO/IEC 14908 
International Standard [12]. 

The most important application area of Lonworks is in 
the building automation industry, but it is also employed in 
the transportation area and in the home automation (in which 
there is currently very considerable growth). 

Lonworks has also a widespread use in industrial auto- 
mation, where, thanks to its features, it can be adopted as the 
unique communication system for the three levels of automa- 
tion shown in Figure 42.1. 

The communication profile of Lonworks is completely 
based on the OSI reference model [13] and implements all 
the protocols and services specified from layer 1 to layer 7. 
The most significant of them are described in the following 
section. 


Physical Layer 

There are various different physical mediums that can be 
used to implement a Lonworks network. 

The stations are connected to segments, called channels, 
by means of transceivers, and a great variety of configu- 
rations may be realized. Channel length, data transmission 
speeds, and a maximum number of stations depend on 
the chosen channel and are completely described in the 
standard. 

For example, the channel type named TP/XF-1250 is 
based on a twisted pair cable and has a bus topology; its 
transmission speed is 1.25 Mbit/s and it can connect up to 64 
stations with a maximum channel length of 125 m. 

Some typical channel configurations are shown in 
Figure 42.7. The use of repeaters and routers allows for the 
implementation of very complex Lonworks configurations 
with considerable geographic extensions. 

Lonworks configurations can also be realized using tra- 
ditional IP networks. In this case, the datagrams specified 



FIG. 42.7 

Typical Lonworks channel configurations. 


by the IP protocol [14] are used to encapsulate the Lonworks 
PDUs. 

Data Link Layer 

Also the data link layer of Lonworks is composed of two 
parts: the MAC sublayer and the Link Layer. 

The MAC uses a CSMA protocol similar to that adopted 
by Ethernet networks but with some modifications necessary 
to limit the occurrence of collisions. This protocol is called 
predictive p-persistent CSMA , and it works as follows. 

A station wishing to transmit senses the network and, if it 
is idle, computes a random time to be waited before the trans- 
mission takes place. When the time expires, if the network 
is still idle, then the station transmits, otherwise, it receives 
the incoming frame and then restarts the delay calculation 
procedure. 

The delay is computed as a multiple of a time interval, 
called Beta2 slot, whose definition is given in the reference 

[15]. 

A station has a minimum of 16 Beta2 slots available. In 
this situation, the average delay calculated for each frame to 
transmit is 8 Beta2 slots. Every station, however, basing on a 
prediction of the network load, has the possibility of dynami- 
cally increasing the number of Beta2 slots up to 1008. With 
this technique, it has been demonstrated that the collision rate 
can be kept constant and independent of the network load. 

The Link Layer realizes the interface with the upper layer 
to which it supplies a connectionless type of services neces- 
sary to transmit and receive data to/from the MAC. The Link 
Layer performs framing, data encoding, and error checking. 

Network Layer 

The concept of addressing is of particular relevance at the 
network layer. In Lonworks, several types of addresses are 
defined. 

The physical address is a 48 bit internal identification 
number (IDN) assigned to every device when built; it is bet- 
ter known with the term Neuron ID. (Neuron is actually the 
name of the commercially available chips implementing the 
layers from 1 to 6, used to realize Lonworks devices.) 

The device address is used to uniquely identify a Lonworks 
station on a defined network. It comprises three different 
fields: the domain ID, the subnet ID, and the node ID. 

The domain ID specifies a set of devices that may 
exchange data among each others. A domain may contain a 
maximum of 32,385 devices. 

The subnet ID refers to a maximum of 127 devices con- 
nected either to a single channel or to a set of channels linked 
together by means of repeaters. Up to 255 subnets can be 
included in a domain. 

The node ID identifies a single node of a subnet. 

Moreover, a group address can be used to specify a group 
of devices belonging to the same domain, but connected to 
different subnets. 
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Finally, a broadcast address may be used to identify all 
the devices of either a subnet or a domain. 

Transport Layer 

The transport layer allows for both the sending and the 
receiving of messages across the Lonworks network. It 
makes available three different services to the upper layer: 
Send_Message, Trans_Completed, and Rcv_Message. 

With the Send_Message service, a message may be sent 
to a single device or to a group of devices. This service, when 
invoked, returns an identifier, named TID, which is used by 
the Trans_Completed service to notify the correct execution 
of the sending procedure. 

With the Rcv_Message, the transport layer notifies to the 
upper layer the arrival of a message received from another 
station of the network. 

There are basically three different ways of exchanging 
messages. 

The Acknowledged Messaging specifies that a source sta- 
tion, after sending a message, receives the acknowledgment(s) 
of the correct reception. A maximum of 64 destination sta- 
tions can be addressed as destinations and acknowledgments 
are expected from each one. In case of time-out in receiv- 
ing the acknowledgment, the message is retransmitted up 
to a number of times specified by a network configurable 
parameter. 

The Repeated Messaging allows for a station to repeat- 
edly send a message to any number of destinations. The 


messages do not require any acknowledgment, and conse- 
quently, the whole transmission has a high efficiency. The 
repetition interval is determined by an internal timer han- 
dled by the transport layer and set by the user requiring the 
service. 

The Unacknowledged Messaging is similar to the 
Repeated Messaging with the difference that, in this case, 
the periodic transmission is not foreseen. 

Application Layer 

This layer also encompasses the presentation layer and is 
mainly concerned with the following functions: 

• Network variable services 

• Generic application messages handling 

• Network diagnostic and management messages 
handling 

• Foreign frame transmission 

These services are implemented by the transfer of appli- 
cation layer PDUs whose structure is shown in Figure 42.8. 

The network variable services are dedicated to the propa- 
gation of messages carrying a special type of data simply 
referred to as network variables. Generic application mes- 
sages are exchanged between application processes resident 
on different stations of a Lonworks network; they typically 
transport data directly related to the involved application 
processes. 


Lonworks application layer protocol data unit 
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FIG. 42.8 

Lonworks application layer protocol data unit. 
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The diagnostic and management messages allow for the 
execution of a set of services such as the router tables main- 
tenance and the querying of stations to obtain their status. 

A foreign frame is defined as a frame belonging to net- 
works different from Lonworks (e.g., IP networks). Lonworks 
explicitly foresees the possibility of being used as a gateway 
between stations connected to different networks. For this 
purpose, the Lonworks application layer offers a set of ser- 
vices necessary to handle the foreign frames. 

As the network variable services represent the most 
important module of the application layer, they are described 
in detail later. 

A network variable is a set of data, normally related to a 
physical process, uniquely identified within a Lonworks sys- 
tem. The variables can be either inputs or outputs. Examples 
are temperature and pressure set points (as outputs), switch 
positions, valve status (as inputs), etc. 

The Lonworks application layer specifies that every net- 
work variable must be of a defined type and, for this reason, 
a set of standard network variable types has been defined. 
Moreover, the device manufacturers also have the possibility 
of specifying a set of user-defined types. 

A procedure defined by the application layer, called 
binding, allows creating a relationship (connection) between 
input and output network variables resident on different 
stations. 

In practice, an output network variable can have some 
readers, located on different stations, and defined in an 
offline phase by means of the binding procedure. When this 
happens, an address table specifying all the readers is associ- 
ated to that output network variable. 

Similarly, these readers must have defined some input 
network variables that have a field internal to their descrip- 
tion, called selector, shown in Figure 42.8, identifying that of 
the output network variable. 

The propagation of network variables takes place as 
follows: when an output network variable is updated, the 
Lonworks application layer checks if there is any reader for 
such a variable (i.e., it checks for an address table). If so, the 
new value is automatically sent to all the stations specified 
in the address table. The application layers of the destination 
stations compare the selector field of the received variable 
with that of the connected input network variables. If they 
match, the value is accepted and passed to the application 
programs through that variable. 

Finally, there is also the possibility that an output network 
variable is connected to an input network variable defined on 
the same station: this is called turnaround connection. 


WorldFIP 

WorldFIP is a general purpose fieldbus designed to be used 
both at the device and cell levels of industrial automation sys- 
tems. It is included in the IEC61158 Standard [15-18], where 
it is referred to as Type 7 network. 
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WorldFIP communication profile. 


The features of WorldFIP allow for its employment 
in several areas of application, for example, the automo- 
tive industry, building automation, process control, and the 
energy production industry. 

The communication profile of WorldFIP is shown in 
Figure 42.9. 

Physical Layer 

The standard foresees the use of either twisted pair or fiber- 
optic cables to implement the physical layer. Possible data 
transmission speeds are 31.25 Kbit/s, 1 Mbit/s (specified 
as the standard speed), 2.5 Mbit/s, and 5 Mbit/s. The latter 
speed is only available for fiber-optic cables. 

If a twisted pair cable is used, several topologies can 
be realized. In particular, the network is divided into seg- 
ments where passive components called Junction Boxes 
may be used to implement derivations. The connection of 
devices to the network can take place using either Junction 
Boxes, or Taps, or active star components called Diffusion 
Boxes. 

A maximum of 32 devices can be connected to a seg- 
ment. The maximum length of a segment is related to the 
transmission speed: 1900m at 31.25 kbit/s, 750m at 1 Mbit/s, 
and 500 m at 2.5 Mbit/s. The covered distances can be incre- 
mented using repeaters. Up to four repeaters can be inserted 
between two stations; in this way, the network maximum dis- 
tance at 31.25 kbit/s is 9500m and the maximum number of 
stations is 128. 

If a fiber-optic cable is used, the network has to be real- 
ized by means of active star couplers to which the stations 
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are directly connected; star couplers can also be connected 
to each others. 

Data Link Layer 

As shown in Figure 42.9, the data link layer provides two 
types of services: periodic/aperiodic services for the exchange 
of identified variables and message services for the handling 
of messages. 

WorldFIP uses two different addressing schemes depend- 
ing on the type of services to be performed. 

Variables, which are distributed across the stations con- 
nected to the network, can be exchanged simply by referring 
to their identifiers, which are unique on the network. For each 
variable, only one producer exists, while there can be more 
than one consumer. A special station, called the bus arbi- 
trator, handles the issuing of production requests. Examples 
of variable types are Boolean, Integer, Bit and Byte Strings, 
Floating Point, Structures, and Tables. 

Messages are exchanged between stations identified by 
means of physical addresses. Each message sent on the net- 
work carries the source and destination addresses. 

The bus arbitrator is responsible for the medium access 
mechanism adopted by WorldFIP. In particular, it has to 
grant the execution of the services mentioned above. 

The periodic variable exchange (which implements the 
cyclic data exchange function) is based on a scanning table 
loaded on the bus arbitrator in an off-line phase. The table 
reports, for each variable, the periodicity with which it has 
to be produced, the type, and the production time calculated 
by the bus arbitrator. During operation, the bus arbitrator 
scans the table and generates the suitable variable produc- 
tion requests. An example of this procedure is reported in 
Figure 42.10. As can be seen, the variable A, which has the 
shortest periodicity, has to be produced every 10 ms and 
determines the duration of an elementary cycle. Every ele- 
mentary cycle is characterized by the production of one or 
more variables. A sequence of these cycles repeated periodi- 
cally identifies a macrocycle. 

Figure 42.10 also shows how the time interval between 
the end of an elementary cycle and the beginning of the fol- 
lowing is available for aperiodic traffic, also handled by the 
bus arbitrator. 

In detail, a station wishing to issue a request for ape- 
riodic activities (either referring to the production of vari- 
ables or to the sending of messages) sets a special bit in any 
frame used to produce a variable during the cyclic opera- 
tion. Consequently, if the request concerns the production of 
variables, the bus arbitrator, in the aperiodic window, will 
request from that station the list of the variables that have 
to be produced. Depending on the time availability, the bus 
arbitrator will then broadcast the production requests on the 
network. 

If, instead, the aperiodic request is for the sending of mes- 
sages, the bus arbitrator, when possible, will grant the request- 
ing station the right to access the network. Subsequently, the 
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FIG. 42.10 

WorldFIP examples of scanning table and variable production 
cycles. 

latter will send the message(s) to the addressed station(s). 
The message transfer services can be either acknowledged or 
unacknowledged. 

It is worth noting that requests for aperiodic activities 
can only be issued by stations that are producers of variables 
exchanged cyclically. 

Application Layer 

Figure 42.9 shows that the WorldFIP application layer com- 
prises two different protocols: the subset of Manufacturing 
Message Specification (subMMS) [19] and the Manufacturing 
Periodic/Aperiodic Services (MPS). 

The subMMS relies on the messaging services offered by 
the data link layer. It allows for the execution of some activi- 
ties such as the set-up and configuration of network entities, 
the download of programs, the monitoring of the variables, 
and the alarm management. 

The MPS is concerned with the identified variables 
that can be exchanged on the network. In particular, MPS 
is responsible for the synchronization of produced and con- 
sumed variables, for the consistency of the data exchanged, 
and for the reading/writing of either local or remote variables. 

ACTUATOR SENSOR INTERFACE 

The Actuator Sensor interface (AS-i) is a fieldbus conceived 
for use at the device level of industrial automation systems. It 
has been designed for a highly efficient exchange of reduced 
sets of data between a master device and binary sensors/ 
actuators referred to as slaves. 
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FIG. 42.11 

AS-i communication profile. 



FIG. 42.12 

AS-i configuration. 


signal is shaped as sin 2 pulses that, thanks to a low content of 
frequencies, limit the radiation emissions. 

The above technique is used with a transmission speed of 
167 kbit/s, which is equivalent to a bit time (the time neces- 
sary to transmit a bit) of 6|is. 


The AS-i is included in both the EN50295 [20] and 
IEC62026 [21] standards. Although these documents specify 
the use of such a fieldbus for realizing the interface between 
control-gear and switchgear in the low-voltage electrical dis- 
tribution environment, the features of AS-i and the low cost 
of its components make its use very convenient also in other 
fields of application. 

As can be seen in the following text, AS-i is particu- 
larly suitable to connect any type of binary field devices 
to a controller, replacing the traditional cabling. The com- 
munication profile of an AS-i master station is reported in 
Figure 42.11. 

Physical Layer 

This layer, named Transfer Physics, is responsible for the 
physical connection between master and slaves. 

The standard specifies the use of an unshielded and 
untwisted cable, which is available in two versions: a gen- 
eral purpose cable to which stations are connected by means 
of traditional screw terminals and a special AS-i cable of 
equivalent electrical characteristics that allows for a direct 
connection of stations by means of contacts that penetrate 
the cable isolation. 

In an AS-i installation, the same cable is used to real- 
ize the data transfer and to power the connected stations, as 
shown in Figure 42.12. Moreover, several topologies such as 
bus and star can be adopted. 

The standard specifies a maximum of 31 slaves for AS-i 
fieldbuses. The longest allowed distance between master and 
slave in an AS-i installation is limited to 100m. Greater dis- 
tances can be covered using repeaters. 

The data transmission technique used by AS-i is named 
Alternating Pulse Modulation: it produces a baseband signal, 
superimposed on the power supply DC voltage. Starting from 
the bit sequence to be transmitted, the resulting modulated 


Data Link Layer 

The AS-i data link layer, named Transmission Control is 
responsible for the access of stations to the physical medium 
and for the correct transfer of information. 

The AS-i transmission control is a bit-oriented protocol 
whose PDUs are shown in Figure 42.13. As can be noticed, 
only two PDUs are defined: the master request and the slave 
response. 

In the master request PDU, the address field is used to 
identify the polled slave, while the information field contains 
the data transferred between master and slave (i.e., process 
data or parameters). 

The communication sequence specified by the protocol, 
also shown in Figure 42.13, foresees a pause of 3-10 bit times 
between the two PDUs and a subsequent additional pause of 
1-2 bit times after the slave response. 

The master request specifies, by means of suitable combi- 
nations of the information field bits, the operation that has to be 
executed on the slaves. The most common of them are Data_ 
Exchange, Write_Parameter, and Address_Assignment. 

With the Data_Exchange master request, four output bits 
are sent to the slave. This latter, on answering, encloses four 
input bits in the slave response. 

The Write_Parameter master request allows for the 
remote setting of some slave options. 

With the Address_Assignment, the master is able to 
set the address of a slave. This operation is possible only if 
the slave has a default address that does not allow for data 
exchange. 

Execution Control 

The execution control manages the overall operation of AS-i. 
It receives the function requests from the user application 
and generates the necessary master calls to the transmission 
control. 
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FIG . 42.13 

AS-i protocol data units and master-slave communication sequence . 


Three different operational phases are implemented 
by the execution control, as described in Figure 42.14: 
Initialization, Start-up, and Normal Operation. 

The Initialization phase foresees a set of actions that have 
to be performed off-line. First, some operational parameters 
of the master have to be set to their initial values; then the 
AS-i power supply has to be tested in order to verify the pres- 
ence of sufficient electrical power for the operation of the 
slaves. After that, the next phase can be entered. 


Initialization 
Setting of additional parameters 
Testing of the power supply 




Start-up 

Detection of slaves 
Activation of slaves 


J 


Normal operation 
Cyclic data exchange 
Acyclic management tasks 
Inclusion function 


) 


FIG. 42.14 

AS-i operational phases of the execution control. 


In the Start-up phase, the master detects and, subse- 
quently, activates the slaves. This operation can be per- 
formed in two different ways: in the protected operation 
mode, the master activates, among the detected slaves, only 
those recorded in a “List of Projected Slaves” table, previ- 
ously prepared by the user. Conversely, in the configuration 
mode, all the slaves detected by the master on the network 
are activated. 

The Normal Operation phase realizes the cyclic data 
transfer between master and slaves, (possibly) some acyclic 
management tasks, and the inclusion function. 

The cyclic data transfer function is outlined in Figure 
42.15. 

The master updates each slave with the output bits and 
acquires from that slave the input bits. This operation is per- 
formed automatically without the intervention of any user 
request. If a slave does not answer, the master increments a 
failure counter for that slave and checks if the same failure 
has occurred for three consecutive queries. If it is the case, 
the slave is marked as faulty and removed from the polling 
list. Then, the master moves on to the next slave. 

The management tasks are triggered by asynchronous 
user requests. At the end of every data transfer cycle, the 
execution control analyzes the occurrence of such requests 
and, if they are present, it forces the transmission control to 
generate the correspondent master calls. Typical operations 
that can be carried out are, for example, reading the slave 
status, setting slave parameters, and resetting a slave. 

The inclusion function allows for the addition of slaves 
to the cyclic data transfer. In particular, the master tries to 
query each slave in the address range 0-31. A single slave 
is queried per cycle. If the slave is already activated, then 
there is no need to include it and the master will address the 
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FIG. 42.15 

AS-i cyclic data transfer. 

next one in the following cycle. If a slave does not answer to 
the query, it means that is not present. Conversely, if a slave 
not yet included in the list of active slaves responds, then the 
master begins to activate it. This procedure takes two addi- 
tional cycles: in the first one, the master reads the identifica- 
tion code of the slave, and, in the second one, the slave is 
definitely activated. 


SERCOS 

Sercos is a network that at its very beginning could not be 
classified as a classical fieldbus (indeed, it was referred as 
the “Sercos interface”). Nonetheless, during the years, sev- 
eral amendments have been brought to the original speci- 
fication and, currently, Sercos is encompassed by both the 
IEC 61158 [22-25] and IEC 61784-2 [26] International 
Standards, where it is referred as Communication Profile 
Family 16. The original version of Sercos was specified by 
IEC 61491, which is now available as a Technical Report 
[27] from the IEC. 

The first version of Sercos (namely Sercos I), issued at 
the end of 1980s, was conceived as a network capable of 
connecting exclusively a control unit and several electrical 
drives at very high communication speeds (2 and 4 Mbits/s 
were available). These devices were arranged in one or more 
rings implemented by means of fiber-optic cables. The sec- 
ond version (Sercos II) was released in 1999 and provided 
some considerable improvements. In particular, the trans- 
mission speed was increased to 8 and 16 Mbits/s, the band- 
width available for the transmission of asynchronous data 



Sercos communication profile. 


was expanded, and, more importantly, the possibility of 
connecting Input/Output stations was introduced. This lat- 
ter feature is particularly relevant since it permits the direct 
exchange of data with general purpose components, mak- 
ing Sercos close to all the other fieldbuses from a functional 
point of view. 

The last version of this network, namely Sercos III, 
has been developed in the context of Real-Time Ethernet 
networks. 

The characteristics of Sercos clearly indicate that it may 
be employed in several fields of applications. In particular, 
since it allows for the high precision control of electrical 
drives, it may be used in applications concerned with motion 
control where, typically, several axes have to be handled. 

The communication profile of Sercos is reported in 
Figure 42.16. 

Sercos I and II Physical Layer 

A typical Sercos configuration is shown in Figure 42.17. As 
can be seen, the control unit may contain more than one mas- 
ter that, according to the specification documents, represents 
the connection of the control unit to the rings. Similarly, the 
connection of a drive to the network is achieved by means of 
a slave. Up to 254 slaves may be accommodated on a ring 
and, it is worth observing, that more drives may be clustered 
and handled by the same slave. 

The fiber-optic cable used for the ring may be either 
plastic or glass, with a step index profile. The Sercos stan- 
dard recommends the use of F-SMA connectors. Different 
distances may be covered depending on the type of cable. 
A plastic fiber allows for a maximum distance between sta- 
tions of 40 m, resulting in a maximum ring length of more 
than 10,000 m. Conversely, with a glass fiber, the maximum 
distance between two stations is 200 m and the overall ring 
length greater than 50,000 m. 
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FIG. 42.17 

Example ofSercos configuration. 


Sercos I and II Data Link Layer 

The operation of Sercos consists of an initialization phase, 
executed only once at system start-up, followed by a cycle 
that is continuously repeated on the network. During the 
initialization phase, the whole system is configured by the 
master that provides the slaves with the timing information 
necessary to access the network during the cyclic phase. In 
practice, as can be seen in Figure 42.18, before starting each 
cycle, the master issues the master sync telegram (MST). 

Then, the slaves access the network, according to the time 
slots notified in the initialization phase. Each slave sends its 
drive amplifier telegram (AT), shown in Figure 42.18, which 
passes through all the remaining nodes on the ring up to the 
master. When the last AT telegram from the slaves has been 
received, the Master Data Telegram (MDT) is broadcasted. 
The contents of the data telegrams exchanged between 
master and slaves are specifically related to the application 
handled by the different devices. Indeed, the AT telegrams 
contain four bytes reporting the status of the slave and a vari- 
able number of data bytes carrying, for example, the values of 
some controlled variables like position, velocity, and torque. 
Similarly, the master data telegram contains four status bytes 
and a data record per each slave. Typically, such data records 
contain the set points for the axes handled by the slaves. 

Besides the cyclic (real-time) transmission, Sercos allows 
for the exchange of acyclic non real-time data such as diag- 
nostic information. This is achieved by means of the so- 
called service channel. In practice, the data are segmented 
in 2-byte fragments that are inserted by the slaves in the sta- 
tus bytes of the AT telegrams, and transmitted, over several 
cycles, to the master that is responsible for their reassembly. 
Acyclic transmissions may only be initiated by the master. 


It is worth observing that the data exchanged on a 
Sercos network are organized in specific structures that are 
addressed by means of identification numbers (IDNs). Over 
500 of these are presently used to define a comprehensive set 
of motion control and I/O variables. Moreover, the Sercos 
standard allows for the definition of 32,767 identification 
numbers (IDNs) that may be used by different manufacturers 
to introduce additional features not handled by the standard. 

Sercos has been designed in order to obtain very short 
cycle times as well as low jitters in the cyclic data exchange. 
In particular, the lowest cycle time selectable is 62.5 ps. 
Other available values are 125, 250, 500 ps and then multi- 
ples of 1 ms. Clearly, the system performance is related to the 
specific features of the applications, for example, number of 
drives to be controlled, amount of data to be exchanged, and 
so on. An interesting case study, in this direction, is given 
in http://www.sercos.com/technology/cyclic_operation_05. 
htm, where a network comprising 1 master and 14 slaves is 
considered. For simplicity, each slave is supposed to handle 
a single drive. In this example, a cycle time of 500 ps may be 
chosen. In such a configuration, the master is able to send to 
each slave one command value (32 bits) and one limit value 
(16 bits). At the same time, each slave may send back to the 
master one 32 bit variable and one 16 bit value. Moreover, 
the service channel is available for the acyclic transmission 
of non-time-critical data at the equivalent rate of 128 kbits/s 
per slave. 

Sercos III 

Sercos III has been designed in the overall context of indus- 
trial Ethernet networks for real-time applications. Indeed, 
this new version of Sercos uses standard Ethernet cables (an 


FIG. 42.18 

Sercos cycle. 
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FIG. 42.19 

Sercos III topologies. 


example is given by CAT5e copper cables with double shield- 
ing) with a data transmission speed of 100 Mbits/s, typical of 
legacy Ethernet networks. 

The basic operation principle of Sercos III is represented 
by the cyclic transmission of a standard Ethernet frame car- 
rying the traditional Sercos telegrams (MST, ATs, MDT). 
The frame, originated by the master, circulates across the 
slaves that elaborate it “on the fly.” In particular, each slave 
reads the data addressed to itself and updates the data for the 
master. It is worth stressing that, with the “on the fly” elabo- 
ration, the Ethernet frame is not received and subsequently 
retransmitted by a slave but, conversely, it flows across the 
network nodes. Such a technique allows for very fast trans- 
missions and, consequently, very low cycle times may be 
achieved. Indeed, Sercos III has a minimum cycle time of 
31.25 |4s, which is half of the lowest value for Sercos I and II. 

In order to maintain the ring structure, each Sercos III 
node has to be equipped with two Ethernet interfaces. This 
allows obtaining two possible topologies, namely, line and 
ring, as shown in Figure 42.19. 

As can be seen, the line topology is equivalent to the 
ring adopted by the original versions of Sercos. Conversely, 
the ring topology represents a double connection between 
master and slaves that may be used to implement redundant 
configurations. 

Besides the characteristics stressed above, Sercos III 
introduces some interesting new features, which make it 
particularly appealing even for application areas differ- 
ent from motion control. Indeed, the principle of operation 
allows that during its circulation, the Ethernet frame may 
be inspected by all the nodes either in the direct path (from 
master to slaves) or in the reverse one. In this way, slave- 
to-slave communication is achieved, simply observing that 
each slave is able to access the data of any other slave. A fur- 
ther interesting innovation is represented by the possibility of 


transmitting IP datagrams within a Sercos cycle. In practice, 
in the Sercos cycle, a new field, namely, the IP channel, may 
be optionally added. In this field, which is inserted immedi- 
ately after the one reserved for cyclic communication, a slave 
may introduce an IP datagram addressed to another device 
in the network. The IP datagram is then transmitted on both 
the Ethernet ports of the slave, so that it is delivered on both 
the directions on the network. A slave analyzes the received 
datagram, and if it is directed to itself, then the slave deliv- 
ers it to its upper layers. Conversely, it simply forwards the 
datagram to the next slave on the ring. 
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